| Author |
Thread Statistics | Show CCP posts - 14 post(s) |
GeeShizzle MacCloud
Caldari
   |
Posted - 2011.04.28 08:29:00 -
[1]
i would suggest looking into the real world physics of dilated time due to gravametric distortions to base TD off of.
...and yes before people jump on the "eve isnt an accurate representation of physics" band wagon, i do believe CCP do make a concerted effort to add a level of realism to keep the immersive nature of main game elements, something that i think should carry on!
and the whole issue of enemy fleets dilating time in a system where timers are ending soon is something that occurs already in one form or another, but is very very rarely taken advantage of. cant remember the last time i was dropped into a system to defend assets, only to lag out for an hour or so. maybe mid fight when successive counter hot drops occur.
with TD all it means is if you're defending assets you should make prior preparations to defend it. it only makes sense!
after all if you fail to prepare, then prepare to fail!
on the issue of cynos i believe cyno's lit in TD systems should have extended active times when being locked onto elsewhere. it makes logical sense to do so.
Every similar situation ive seen in science fiction when an outside observer views streamed moments affected by dilated time the moments are stretched and extended in duration. this should be the case with active cynos in a TD system.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 13:14:00 -
[2]
Edited by: GeeShizzle MacCloud on 28/04/2011 13:20:43
i think people need to realise TD will have a marked impact on the DURATION of activation... not the delay between pressing the button and seeing the result. in actual fact the last part of that sentence is exactly what TD solves!
it amazes me how feral people get at changes and its effects to the point that they loose sight of the initial principles of the design brief!
if you're in a dilated system for 7 hours guess what... your clock at the bottom left should and will be the same as everyone elses, even people in jita etc...
POS timers should run separately from TD's effects, in fact its vastly easier to rule out what shouldnt be affected by TD than what should.
The list for what will be affected will quite obviously be much larger than the list of what shouldnt.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 14:38:00 -
[3]
im not too sure what u mean by spectrum.. unless u mean the sinclare one!
bt yahh think the matrix, think max paine etc... everything runs slower and because of that smoother. technically people could record the fights and then in a video editor speed it up to normal speed with ultra smooth movements!
the effects of TiDi are even and all encompasing in terms of ship movement, combat module cycle time etc... basically everything to do with navigation weaponry and the like. because of this gameplay is still completely fair and unchanged in terms of balance.
if you want i could try brainstorm a list of stuff that would be affected by TiDi? tho it will be pretty long!
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 17:24:00 -
[4]
 Originally by: Firiya Boomsloop
I'll geek out a bit :)
...The trick is going to be determining what factor of TiDi to apply, balancing flow of the game (close to real-time as possible) versus predictable behavior (avoiding the random glitches from overloading).
thats where the testing on sisi and duality will come in i think.. but tbh i can see veritas applying TiDi on every server apart from he jita node.
in terms of TiDi as a tool for veritas to use, he could balance it so that he keeps 15 to 20% of the servers CPU for calls that TiDi doesnt affect. that way the calls will be processed faster without too much of a noticable difference on grid.
in essence use TiDi as a buffer.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 19:22:00 -
[5]
Originally by: CCP Veritas
Ah, indeed, I did miss that. That too is Not Cool for exactly the same reason though - it allows people to move timers, just in the other direction.
fully agree and support veritas on this!
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 21:07:00 -
[6]
I think the spamming of commands to move here n there, activate this and that, when its genuine and not malicious, stems from when as a player your client doesn't respond.
This should alleviate this aggravation, and yes you are right that people will be able to still spam as much as they do now. the server tick/second isn't being extended btw. so it wont increase the spam.
It'll just be blatantly obvious who's being a d**k to veritas and his hamsters.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 00:00:00 -
[7]
Originally by: Commander Predator
I would assume locking time would be dilated too correct?
yes it would
Originally by: Commander Predator
edit* also what about missile boats even though i hate them, wouldnt time dilation essentially slow the time it takes missiles to reach point a to b and slow the activation timer down?
missile boats have a fair few time based variables. module cycle time would be lengthened, missile flight time would be increased inversely proportional to missile velocity.
so the missile will still travel the correct distance, just at a slower pace but for an extended length of time.
explosion velocity would also decrease in line with ships reduced velocity so to keep the original game balance/mechanic intact.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 07:46:00 -
[8]
Originally by: Heavy MG
I don't see the difference between everything moving slowly or being stuck frozen. Either way things take forever to clear out.
difference is with TiDi your ship and actions will start happening pretty much immediately, showing that your button mashing hasnt been in vein, and that you dont need to keep button mashing for the next 2 or so minutes.
this = better server performance = better gaming experience for all!
Originally by: Heavy MG
Why doesn't CCP implement a system that automatically loads a node onto an empty cluster/server when the users reach a certain limit? This system would always be dedicated, and you could have more than one. That way things would work normally, call it "automatic" reinforcement.
because currently thats not possible unless you disconnect every client/player on that server and swap it over before any1 rejoins the game. CCP believes that to be immersion breaking and in some way unfair. so if you know a fleet fight is going to take place in a system and between now and then there is downtime you can fill in a Fleet Fight Notification Form, which will swap that system and a few of the surrounding systems onto a dedicated server.
to be fair ive been in that situation coming out of downtime on a non-reinforced server and lag became unbearable with everyone in system trying to rejoin a variety of fleets, along with loading grids and starting fights. it was absolutely appalling.
joining fleets in that situation i believe caused sooo much lag on the server... could be another important area to make server requests more efficient btw!
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 11:42:00 -
[9]
Originally by: CCP Veritas
Any location node (server running space stuff) will be capable of being dilated. That said, Jita hasn't come close to 100% CPU since we changed inventory to use sets. Sooo...Jita will continue to be just fine.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 17:13:00 -
[10]
Originally by: Bladacticus
I didn't have time to read through the entire thread, but I'm concerned by this.
you're obviously not.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.30 08:58:00 -
[11]
Edited by: GeeShizzle MacCloud on 30/04/2011 09:00:50
Originally by: Cosmoes
Sounds interesting and looks like a pretty good solution two thoughts though.
You mentioned all systems on same node get time dilated. I'm not sure how it's currently set up but unless nodes are placed in systems based on physical location (neighbouring systems on same node) it could cause problems.... also what will this do to a system like Jita?
My second point is that players are the only place I see this going wrong. If you are slowing down the system waiting for commands to be done then we will see quite a long delay in responding to our commands. If we take 5 minutes to catch up on the initial calculations of warp in and launching drones and activating modules players are gonna freak out during those 5 minutes.
Even if you slow down the time so general calculations are slowed down how about player input? If you have 3000 players spamming the warp button non-stop for 5 minutes while you are catching up on the warp in command how is time dilation gonna deal with a massive build up of player input?
you have obviously:
1) not been in a laggy fleet fight before
2) not read and understood the dev blog
3) not read even the last few pages of the discussion
i would suggest u acquaint yourself with the principle of TiDi and the discussion before embarrassing yourself.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.30 10:50:00 -
[12]
yes you are.
if mining and battle starts at 10:00 in those 30 minutes (dilated or not) both groups of people will see their clock at 10:30.
people need to get away from this misconception that TiDi dilated everything. it doesnt.. theres no requirement to catch up time, cause theres no 'lost' time.
the only possible exploit that TiDi might create is the possibility of a fleet to jump out of a system affeted by TiDi via gates and be able to rep shields/armor/hull faster due to a more restored module duration.
but even in doing that it presents a tactical disadvantage of having to load the system and grid again when jumping back in.
Plus having a fleet leave a system would mean load is decreased so the advantage of jumping out and repping is reduced merely by trying it, as the enemy fleet in the system you've jumped out of will have its TiDi effects reduced and be able to rep faster too.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.02 11:52:00 -
[13]
Edited by: GeeShizzle MacCloud on 02/05/2011 11:54:49
well as much as cloud based computing would be just epicly awesome for Eve, theres sooooo many important factors and hurdles to consider before even trying to plan something like that out.
not only is there the security issues, the bottlenecking and throughput problems and lag caused by sending information all over the world from iceland and waiting for it to come back, to only send it out again, you couldnt guarantee the computers opted in are not doing it maliciously, or trying to degrade gameplay for some advantage, whether game related or even as a rival business in the same industry.
The one thing i absolutely LOVE about Eve is the fact its soooo robust in comparison to other games. theres very little if any cheating that happens in eve. some may say metagaming in eve is a form of it but in comparison to other gaming titles out there eve is almost surgically clean of hackers and exploits!
the cloud computing thing is a perpetual minefield to be fair and i doubt CCP as a business would want to open itself up to that level of multi-pronged attacks. itll be like running into a packed stadium, standing legs apart and pointng at ur crotch shouting "hey everyone, kick me in the nuts!"
i would add that i do love that idea... (not the kick me in the nuts one! but Vigo Plesh's) just wish the real world wasnt soo much of a c**t about these things.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.09 21:28:00 -
[14]
Originally by: Rockin RicciBobbi
Quote:
"Here's how I envision this working for a large engagement (say, 1600 or so). When the attacking fleet warps in, the server gets extremely overloaded - warp-in and other setup tasks like drone deployment are quite expensive - so the game clock gets dilated extremely, down to 5% of real time or something."
Some of my toons have been in large fleet engagements that lasted 4 hours. Even a 50% time dilation is not feasible in many cases and allowing time dilation down to 5% is just plain idiotic. Here is why: Players will find ways to exploit and manipulate the game mechanics to maintain such time dilation to their side's advantage. To use one example from the dev blog: by continuously warping a large fleet around and deploying drones. So now we have the possibility of what would otherwise be a 1 hour engagement stretched to 20 hours. Or a tower being attacked with plenty of time to reinforce before downtime/server reboot except the defending fleet can just dilate time instead of actually engaging to keep that from happening. That is ridiculous. I know more complicated scenarios about exploiting time dilation have already been mentioned, but just think of the very simple unpreventable ones. We need fewer exploitable game mechanics instead of CCP creating more and more. Crashes and disconnects and desyncs suck, but that is better than adding a time dilation mechanic. How is all that added code to make time dilation work going to make Eve more efficient overall? It's not. It's like claiming that you're making the Boston Marathon shorter by making everybody run slower.
The game has become a victim of its own success and most easy fixes have been tried. Time dilation would fix some of the symptoms associated with large fleet fights instead of making Eve work as promised and as advertised. A real solution will be difficult but we don't need another work-around bandaid. Given CCP's ever-increasing willingness to concentrate on their internal metrics instead of the user experience, I am not surprised at this proposal.
your arguments are soo full of holes and knowledge of the subject its rediculous
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.10 11:27:00 -
[15]
 excelent! time to get into some good arguments once more!
Originally by: Rockin RicciBobbi
Originally by: GeeShizzle MacCloud
The one thing i absolutely LOVE about Eve is the fact its soooo robust in comparison to other games. theres very little if any cheating that happens in eve. some may say metagaming in eve is a form of it but in comparison to other gaming titles out there eve is almost surgically clean of hackers and exploits!
I really like how delicately you sanitize botting "some may say metagaming..." Some may say the hordes of mission running and mining bots in highsec, the trade-bots in Jita, and rat-bots in nullsec, are a violation of the TOS.
if you'd bother to actually read that conversation i was refering to the combat orientated side of eve gameplay here so stop trying to derail the subject and quote out of context, go read up Quoting out of context
Quote:
Lag is caused by shortcomings in latency, system resources, and programming efficiency. That is what must be addressed.
Well please tell us and ccp how to bend the laws of physics to make a zero-lag MMO reach across the entire globe. ohh and while ur at it u can build that quantum computer uve been sketching down and rewire every country in the world's communication infratsructure to be ultra efficient and hyper fast.
Yes i was overexadurating and it was to prove a point. CCP and Eve online have to live in the real world with real world problems both in terms of technical ability and financial capability. yes we'd all like CCP to have the world largest and fastest servers and data throughput but unless they get a blank cheque thats guaranteed not to bounce they have to look to more real world fixes for these problems.
some could say that there is a way to go for programming efficiency and you'd be right... but its a slow and complicated process. Veritas has already estimated that going multicore 4 wide from a single cpu with the servers may only achieve between 2 to 3 times increase in speed. and re-programming eves servers to do so would take a collossal amount of dev time.
Originally by: Rockin RicciBobbi
This is yet another example of how CCP wants to put a bandaid on something that requires open-heart surgery.
Time Dialation is the equivalent of putting a pacemaker on a person heart. where as what you want is the heart to be totally replaced. yes ideally that might be the best choice but CCP have made a decision to persue the avenue that provides the best performance to development time, and TD clearly is it. if you dont think so then ill give you a demonstration....
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.10 12:05:00 -
[16]
Time dialation as you should know is designed to reduce the amount of incoming requests to the server so to keep a buffer between the used CPU %age and its maximum. the reason for this is so that other higher priority requests that are not explicitly combat related (such as jumping in and out etc..) can be handled promptly and immediately. Veritas has said somewhere that even with TD on it may not have the effect of reducing requests by half when at half speed. TD is more likely to only be half as efficient as originally hoped. so the number of clients a typical server will be able to handle may only increase by 50% when the server halves the playing speed.
say an average server can cope with 400 to 500 players in one system dualing it out without time dialation coming into play. with TD slowing the pace to half speed as more fleets jump in (with jumps and grid loading happening immediately) that 500 player no-lag server can now accomodate 750 without visable lag.
Say more come into the fold again and TD increases to 1/4 of the speed it was originally. the same server can now accomodate 1125 relatively lag free with jump ins and grid loading happening immediately... we carry on and add more... TD halfs the speed again so its running at 1/8th the speed originally (or 25%). The same server can now cope with 1687 players.
By half again (down to 12% of original speed) means 2531 players relatively lag free but as a much reduced speed.
Now... coding the eve servers to use multicore CPU's will yield an increase of at best between 2 and 3 times current. taking 2.5 times as a conervative estimate means that same 500 player server will be able to perform to 1250 players before module lag, de-syncs and no-load grids etc... and i do believe many people in null sec have seen and been in fights larger than that before. Meaning people will still complain even after eve goes multicore about the fact they lost their super unfairly cause they had a grid that didnt load or their ship didnt align or jump out when it was possible to.
With TD you could say that at 1/16th speed, a 1 hour battle can technically last 16 hours and that compared to where we are now that isnt any form of improvement. saying that though shows ignorance to this situation in the real world. no fight is going to start at 1/16th speed with 2.5k pilots in 1 system waiting in optimal for everyone both friend and foe to be ready, fights like this escalate over a course of time and amazingly enough, people do die and the numbers are reduced somewhat.
Even so, the problem with fleet fights of that scale currently is the lost requests meaning clients rage and log and re-log.. causing more requests and more lag. TD means expensive requests like loading grid and jumping into a system woould be handled immediately.. meaning no rage and no relogging.
the argument that FC's will use tactics that are expensive to the servers CPU is valid, but has been argued about waaaay before this. i even asked veritas himself about the ability to monitor requests sent by individual clients that are above normal. specifically to keep an eye out for these tactics and he's assured me that he'll have something evil and terrifying for people who do deliberately overload the servers, if it occurs.
you could ask why something like that hasnt been created before and thats because module lag has always been an issue. many pilots dont realise that spamming a module activation when its unresponsive only adds to the problem. with TD in place and active its extremely unlikely you'll ever see module lag again. so the genuine spammers wont be raging and spamming and saying eve is broke blah blah blah. keeping an eye on server requests by client ID on a server with TD running will quickly show up the users deliberately trying to overload the server. so if you are one of those super pilots spamming ur 30 or so fighters to attack then return to orbit and so on, expect to be noticed and expect repurcussions
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.10 12:18:00 -
[17]
tbh i for one want to see eve servers go multicore, but i seriously believe TD is more beneficial for fleet fights and would be quicker to code and implement than going multicore.
so TD > Mulitcore, but we have to make sure after TD is done and working well that veritas and his team gets to work on getting the servers running on quad cores, after all a quad core server runing with TD has epic stats!
taking that typical multicore server i postulated in the post above, being able to handle 1250 players with no lag and slapping TD on it means at 25% speed (1/4th of original) itll be able to handle 2812 players!! thats very close to the largest feetfight in eves history, at a quarter speed but LAG FREE!!
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.10 23:46:00 -
[18]
Edited by: GeeShizzle MacCloud on 10/05/2011 23:47:41
wow... just wow...
... have i missed some sort of full moon or something?
i have said it a thousand times before and i will keep saying it until people realise what i am saying, TD is a system that brings massive fleet fights from its current area where clicking on stuff doesnt do things for ****ing ages (how on EARTH can u say u prefer something thats actually borked and screwed up) to clicking stuff and it actually doing it immediately.
this LAG u all talk about isnt lag you would experience in any FPS game, its got absolutely nothing to do with your ping to the ccp servers. Its the servers ability to respond to the sheer volume, yes VOLUME of your requests.
so yes veritas could work on multicore stuff bt it'll prob take him 12 to 24 months at least to complete and initial form, then comes ironing bugs out of to the point the servers dont do really strange stuff that degrades players gameplay unexpectedly and without any obvious rational reason. you really want that??? and have 2+ more years of what we have right now?
so you would prefer for the McBlobs to rule for 2 or more years until moderately large scale fleet fight become relatively okay and large coalitions decide that they can just ramp the blobs up a tad more?
TD takes the current broken combat mechanics of large scale fleet fights and PRESERVES THE MECHANICS OF THE ORIGINAL GAME regardless of the blob size! HOW THE **** is this some sort of advantage to blobs??? if anything its an advantage to more experienced FC's to use game mechanics that actually beats blobs!! (say umm... large bomber fleets btw??)
the only main reason that blob warfare is successful currently is cause u dont jump into a blob in a high population system cause ur ships DONT ****ING LOAD GRID FAST ENOUGH and you end up dieing before you can do much of anything!
i ask you HOW IS THIS FAIR, HOW IS THIS IN ANY WAY WHAT A GAMES DEVELOPER WOULD ULTIMATELY WANT? its not.. its a population pushing a product to the point it doesnt work anymore.
so someone NOT from CCP comes up with an idea to fix the game.. and you start saying its CCP ****ing up again? go ****ing check what ur saying idiots.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.15 10:27:00 -
[19]
excuse me for jumping te gun and assuming something here but FC's require intel in order to gather an understanding of a battlefield.
either this can be done on the assumption of what a typical fleet fielded by a certain alliance does based on experience, or gained on the field there and then by the effects observed by the FC and his/her team.
the latter has rarely been possible in large fleet fights (aka ones with 100 or more capitals on either side) because the lag causes the game to be soooo much more choppy/unresponsive
as i see it there are a plethora of new tactics that can be implemented on a large scale fight if commands are made as responsive as those in small scale gang pvp, even if the pace of those fights slows considerably.
Davet517 is totally right that the slowdown will help slow inexperienced FC's, but it wont stop an actual bad FC make the wrong decisions.
So the comment about it helping/aiding blob warfare is a blatant show of your narrow minded fc skills and lack of creative thinking on the subject.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.16 20:51:00 -
[20]
looks a lil convoluted and im sorry bout that!
Originally by: Rassad2
So as I understand it.. Time will "slow down" for an entire system, when 1000 Ships deploy drones, or land on a grid etc.
So what happens If a fleet of 1000 people, decide to use Tidi as a tactic?
Example:
A fleet of 1000 people deploy drones.
recall drones...
deploy drones...
recall drones...
deploy drones...
Thus Tidi slows down all timers in the system greatly.
If the fleet See's a hostile fleet incoming on scanner, they recall drones, and fleet warp to a new safespot.. and repeat.
What prevents a fleet from keeping a system constantly Time dilated? for whatever advantage that will give them?
Originally by: GeeShizzle MacCloud
if anything Bosse could write an automatic program that can hunt down clients sending massive amounts of requests compared to a normal amount for a particular ship (as SC's will be putting out more requests to the server from fighters etc than an ecm BS for example.)
what bosse wants to do with these people is up to him and CCP, but forcing a client DC with a re-logging cooldown timer i dont think would be that harsh bearing in mind what that person is trying to do.
I'd loooove to know if this is possible... as im sure you can group server requests by ip address and watch over them to look for excessive levels.
Originally by: CCP Veritas
If it becomes a problem, yo, I'll solve it.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.25 00:14:00 -
[21]
what... do u think they're just not doing hardware upgrades or something?
did you not hear at fanfest that they've received special purchase of a new cutting edge, still unannounced IBM server with an un-released CPU from Intel costing $50,000 a piece??
im sorry if u think u could put together a better server farm with better performance by going down to wallmart and buying a few pc's and linking them together bt id say that CCP are looking at server performance very very very seriously! u dont just drop 50 large on a whim!
jeez some people!
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.05.25 22:37:00 -
[22]
well if thats the attitude u have then u can believe whatever the **** u want... u can choose to believe that that "box" they wheeled into the fanfest was a new server or u can believe that that box contained all the secret US governmental data on JFK's assassination.
you can believe that people at ccp hq in iceland actually do work on improving eve online slowly but surely or you can believe that they constantly dodge pyroclastic flows while firing ping pong balls out of their asses!
im not gonna try and change what u believe theyre doing. im here to be constructive and provide an objective and alternate viewpoint on what theyre working on.
though i have to say u sound like the kind of person that believes we should all be dieing painfully at the moment in the "rapture" or some BS like that. hope ur faith wasnt too shaken by the godly no-show! expect it to occur for the rest of your life.
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.06.06 18:15:00 -
[23]
Originally by: Livini Naship
i dont like this idea, and i dont know why its called "time delation", its just slowing down the information signals in large scale battles in that sector and adjacant sectors.
no its not. go back to the "official" sources of information on the subject and re-read.
Originally by: Livini Naship
i think much ppl will suffer everytime when there is an battle somewhere, because its their playing time the server system is stealing them to give it to someone else that wants to fight.
more than it does so now? i dont think so! at least you wont loose assets to random bits of lag like u can do currently.
Originally by: Livini Naship
also i think it will get exploited.
well if you seem to know so much please give us your insight into how it will most likely be exploited
Originally by: Livini Naship
i see much problems with this strategy because its not solving the real problem at all, the signal processing speed.
well thank god you came along! i guess you design and build faster processors then Intel then?
CSM Prop 1
CSM Prop 2 |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.06.07 16:11:00 -
[24]
tbh i do seriously need veritas to see this!!
just wanted to let him know that if the videos coming out to do with the "future vision" of eve and the new DUST514 one with weapons fire between static structures and orbital capital ships are to become a reality he will need to liaise with the dev's in shanghai and newcastle about the issues of server lag and the implementation of time dilation into Dust514.
As de-sync's between the two while theres weapons fire between them will cause A LOT of rage from cap pilots.
CSM Prop 1
CSM Prop 2 |
| |
|